This web site is not some kind of 'official' documentation hub for the XT-IDE card.
It is simply the result of someone who decided to add to the documentation that exists elsewhere.
XTIDE Universal BIOS - Late initialization
Background
INT 19h (interrupt 19h) is the 'bootstrap loader' interrupt. It executes code that boots to something (disk, motherboard BASIC, etc.). INT 19h is called as the last action of the computer's power-on self test (POST). By default, INT 19h points to 'bootstrap loader' code in the motherboard BIOS ROM.
Redirecting (re-pointing) INT 19h
Example: In an IBM XT, the stock IBM BIOS ROM on the motherboard knows nothing about hard drives. The INT 19h code in that BIOS ROM simply looks for a bootable floppy, and if not found, boots into Cassette BASIC (BASIC in ROM's on the IBM XT's motherboard). When an XT-class hard disk drive controller is fitted, the initialization code in its BIOS ROM does a few things, including adjusting interrupt vectors. That is shown/commented at here for the case of the 'IBM Fixed Disk Adapter' (the stock MFM HDD controller in the IBM XT). You can see that the INT 19h vector is being re-pointed, pointed to replacement 'INT 19h bootstrap loader' code in the BIOS ROM of the IBM Fixed Disk Adapter. Then, when INT 19h is called (end of the POST), that replacement 'INT 19h bootstrap loader' code boots using the following drive priority sequence: floppy, then MFM hard drive 0, then motherboard BASIC.
The initialization code in the XTIDE Universal BIOS (XUB) is also something that re-points the INT 19h vector, to replacement 'INT 19h bootstrap loader' code (XT-IDE aware) in the XUB. In very early XUB versions, that replacement INT 19h code would have been just 'boot from something' type code.
So a problem exists if during POST, something running after the XUB's initialization code, yet again re-points the INT 19h vector to somewhere else. (I.e. the replacement 'INT 19h bootstrap loader' code in the XUB would never get executed). An example is: ROM in XUB @ C8000, ROM in XT-class MFM controller @ D0000. (Luckily, the norm is the opposite, XT-class MFM controller @ C8000, XUB @ D0000.)
Late initialization
In 2009, the XUB started to use 'late initialization' (for XT builds of the XUB).
With 'late initialization':
• During the POST, the initialization code in the XUB will be called. All that the code does is re-point the INT 19h vector to replacement INT 19h code (XT-IDE aware) in the XUB. (E.g. No display of XUB banner/splash text happens at this time.)
• At the end of the POST, the POST executes INT 19h. As a result, the INT 19h code in the XUB is executed. Display of XUB banner/splash text happens at this time.
Late initialization means that at the time that the XUB displays its banner/splash text, the XUB should be aware of all drives.
The aforementioned potential problem still exists: During the POST, the initialization code in the XUB needs to be the last thing to re-point the INT 19h vector.
Although late initialization can be turned off in v1.x.x versions of the XUB (example at here), turning it off via an early XUB version would result in various issues, the two main ones being:
• Early versions of XUB have bugs that are fixed in later versions.
• v1.x.x versions of XUB do not support the hi-speed mode of XT-IDE cards. See here for information about hi-speed mode.
Late initialization is introduced by aitotat at here.
Very late initialization
If the aforementioned problem exists (for whatever reason, a reason that cannot easily be fixed/bypassed), then one answer is for the initialization code in the XUB to re-point a different interrupt, an interrupt that is known to be called at the end of the POST.
With 'very late initialization' activated, the XUB re-points INT 13h, not INT 19h.
'Very late initialization' can only be activated by doing a custom build of the XUB.